I've an asp.net web application hosted on a web server(IIS 7).It uses Lucene for search functionality.
Lucene search requests are served by .Net WCF services sitting on 2 application servers (IIS 7).The 2 application servers are Load balanced using "netscaler".
Both these servers host a .net windows service which updates search indexes on the respective servers in the night on a daily basis.
I need to synchronize search indexes on these 2 servers so that at any point of time both the servers have uptodate indexes.
I was thinking what could be the best architecture/design strategy to do so given the fact that any of the 2 application servers could be serving search request depending upon its availability.
Any inputs please?
Thanks for reading!
Basically you need two identical copies of the same Lucene index - one for each IIS server.
I believe the simplest approach is to build an updated index on one machine, optimize it and then copy it to the other machine. On Linux I would use rsync, but I do not know the Windows equivalents. See Jeff Atwood's ideas for Windows rsync alternatives.
Alternatively, you could issue the same index update commands to both Lucene indexes and verify they were processed properly. This is harder technically and only useful when you have more frequent updates. Please see Scaling Lucene and Solr for a broader discussion of distributed Lucene indexes.
Related
We have built the ASP.NET MVC4 application and deployed on IIS8.5
We updated setting in Appication pool for QueueLength = 5000 and also updated the same in ASP.NET.config file of framework (C:\Windows\Microsoft.NET\Framework64\v4.0.30319)Appication pool setting upate
ASP.NET Config file change
Still, max 100 users are allowed in one go and rest being queued.
Server configuration is 4 core processor, 8 GB Ram and 64-bit OS.
Need help to fix my problem. many many thanks in Advance.
Attached image of all configuration.
We updated setting in Appication pool for QueueLength = 5000 and also updated the same in ASP.NET.config file of framework (C:\Windows\Microsoft.NET\Framework64\v4.0.30319)
Allow maximum number of users with concurrent login and support.SServer Configuration
Need help to fix my problem. many many thanks in Advance. Attached image of all configuration.
I suggest you could run below command to modify the appConcurrentRequestLimit in server runtime in applicationhost.config file.
c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000
However,I would like a recommendation from you regarding two options we have. 1 We can Update my existing server from 4 Core 8gb RAM to 6 core 16 GB RAM or 2 We can Keep separate servers i.e One for IIS and One for SQL Server. Server Config will be same for both(4 Core 8GB RAM). Which option would be preferable?
In my opinion, this should according to your application performance. I think you should analysis the sql's performance, if you find the sql has takes a lot of server's resource to handle the sql query or something elese which cause your IIS takes so long time to response, I suggest you could keep separate servers.
If you find the sql server just take a little server resouce, I suggest you could use use just one server.
Currently, ElasticBeanstalk supports ASP.NET Core applications only on Windows platforms (when using the web role), and with Windows-based platform, you can't have Immutable updates or even RollingWithAdditionalBatch for whatever reason. If the application is running with a single instance, you end up with the situation that the only running instance is being updated. (Possible reasons for running a single instance: saving cost because it is just a small backend service, or it might be a service that requires a lot of RAM in comparison to CPU time, so it makes more sense to run one larger instance vs. multiple smaller instances.)
As a result, during deployment of a new application version, for a period of up to 30 seconds, you first get HTTP 503, then HTTP 404, later HTTP 502 Bad Gateway, before the new application version actually becomes available. Obviously this is much worse compared to e.g. using WebDeploy on a single server in a "classic" environment.
Possible workarounds I can think of:
Blue/Green deployments: slow (because it depends on DNS changes), and it seems like it is more suitable for "supervised" deployments, not for automated deploy pipelines.
Modify the autoscaling group to enforce 2 active instances before deployment (so that EB can do its normal Rolling update thing), then change back. However it is far from ideal to mess with resources created and managed by EB (like the autoscaling group), and it requires a fairly complex script (you need to wait for the second instance to become active, need to wait for rolling deployment etc.).
I can't believe that this are the only options. Any other ideas? The minimal viable workaround for me would be to at least get rid of the temporary 404s because this could seriously mislead API clients (or think of the SEO effect in case of a website if a search engine spider gets a 404 for every URL). As long as it is 5xx at least everybody knows it is just a temporary error.
Finally, in Feb 2019, AWS released Elastic Beanstalk Windows Server platform v2, which supports Immutable und Rolling with an additional Batch deployments and platform updates (like their Linux-based stacks already supported for ages):
https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-02-21-windows-v2.html
This solves the problem even for environments (normally) running just one instance.
So, in my WCF service, I will be caching some data so future calls made into the service can obtain that data.
what is the best way in WCF to cache data? how does one go about doing this?
if it helps, the WCF service is multithreaded (concurrency mode is multiple) and ReleaseServiceInstanceOnTransactionComplete is set to false.
the first call to retrieve this data may not exist therefore it will go and fetch data from some source (could be DB, could be file, could be wherever) but thereafter it should cache it and be made available (ideally with an expiry system for the object)
thoughts?
Some of the most common solutions for a WCF service seem to be:
Windows AppFabric
Memcached
NCache
Try reading Caching Solutions
An SOA application can’t scale effectively when the data it uses is kept in a storage that is not scalable for frequent transactions. This is where distributed caching really helps. coming back to your question and its answer by ErnieL, here is a brief comparison of these solutions,
as Far as Memcached is concerned, If your application needs to function on a cluster of machines then it is very likely that you will benefit from a distributed cache, however if your application only needs to run on a single machine then you won't gain any benefit from using a distributed cache and will probably be better off using the built-in .Net cache.
Accessing a memcached cache requires interprocess / network communication, which will have a small performance penalty over the .Net caches which are in-process. Memcached works as an external process / service, which means that you need to install / run that service in your production environment. Again the .Net caches don't need this step as they are hosted in-process.
if we compare the features of NCache and Appfabric, NCache folks are very confident over the range of features which they ve compared to AppFabric. you can find enough material here regarding the comparison of these two products, like this one......
http://distributedcaching.blog.com/2011/05/26/ncache-features-that-app-fabric-does-not-have/
I am looking for suggestion for hosting my WCF enterprise application.
The app. require to run without stopping at the server. It also use TCP to yield the best performance at the intranet environment.
I am thinking to host it at window service because IIS recycle process, and has timeout.
However, I find this from the msdn http://msdn.microsoft.com/en-us/library/ff649818.aspx :
Window service...Lack of enterprise features. Windows services do not have the security, manageability, scalability, and administrative features that are included in IIS.
Does it mean Window Service is not suitable for enterprise application? But How about MS SQL, Oracle, MySQL etc. They all host at Win. Service right?
Regards
Bryan
Windows service is suitable for enterprise application! The quoted text actually means that IIS has a lot of built-in management features which are not available in custom hosting (like windows service) unless you implement them at your own.
One of such features is the recycling you want to avoid which helps application to keep low resource consumption (server is in healthy state). Another such feature is IIS checking of the worker state. If worker process looks stuck (don't process requests for any reason), IIS will start automatically another process and routes new requests to that process.
IIS + WAS + AppFabric can provide very big feature set but they are not good for every scenario. If you have service which requires some background continuous, scheduled or multi threaded processing it is probably better to move to self hosted scenario.
I have an application that is load balanced across two web servers (soon to be three) and deployments are a real pain. First I have to do the database side, but that breaks the production code that is running - and if I do the code first the database side isn't ready and so on.
What I'm curious about is how everyone here deploys to a load balanced cluster of X servers. Since publishing the code from test to prod takes roughly 10 minutes per server (multiple services and multiple sites) I'm hoping someone has some insight into the best practice.
If this was the wrong site to ask (meta definitely didn't apply - wasn't sure if serverfault did as I'm a dev doing the deployment) I'm willing to re-ask elsewhere.
I use nant scripts and psexec to execute them.
Basically in the farm there's a master server that copies the app and db scripts locally and then executes a deployment script in each server in the farm, that copies the code locally, modifies it if needed takes the app offline deploys the code and takes the app online
Usually the app is of for about 20 seconds (5 nodes)
Also, I haven't tried it but I hear a lot about MSDeploy.
Hope this helps
Yeah, if you want to do this with no downtime you should look into HA (High Availability) techniques. Check out a book by Paul Bertucci - I think it's called SQL Server High Availability or some such.
Otherwise, put up your "maintenance" page, take all your app servers down, do the DB and one app server first, then go live and do the other two offline.