I want to know what is the difference between these two implementations of neo4j. Of-course names of both techniques is self-explanatory,but still what are the main differences?
What factors should be considered in deciding which technique to use in the project?
Pros and cons.
P.S. Sorry if it is a repeat question but I searched and was not able to find any ques which answers my question.
Because the standalone server is built on the embedded server, the general rule of thumb is that the embedded server is more capable and has (obviously) lower latency. Either can operate in High-Availability mode, allow monitoring, and even accept connections from the neo4j-shell. With the server though, you get more functionality out-of-the-box, like remoting, basic visualization, monitoring interface, etc.
The differences are otherwise the practical ones you'd imagine. Choosing a deployment approach is influenced by two things:
Language - embedded mode requires that you're implementing your application with a JVM compatible language. The server supports any language/framework that can send HTTP requests.
Hardware - sharing physical resources between your application and Neo4j can be demanding. Scaling may argue for a dedicated machine to split out the persistence layer. The server obviously has a remote API to support segmenting your application.
It's otherwise difficult to give guidance without a specific usage scenario. Deploying into an existing Service Oriented Architecture? Probably server. Running on an copier machine? Go embedded. From scratch web application? What's the rest of your stack?
Related
We are a startup and currently in the evaluation mode for using SUAVE with F# as the web application development framework. I am very enthusiastic for using the SUAVE framework for developing my applications.
I just want to know if SUAVE is production ready and if any performance benchmarking has been done on it as compared to OWIN for concurrent users and how many user traffic can the web server handle.
Altough this thread now 8 months old, I wanted to share my experience with using Suave as web server.
First, measuring performance based on simple benchmarks won't tell you the truth about the overall performance of a more complicated system.
However, when using Suave, it's unlikely that it will be the bottleneck in your application.
It depends a lot more on the entire architecture, the sum of mechanics between request and response, and implementation details (e.g. random access on Lists is rather slow).
I used Suave in 3 projects now, always with great success.
All of them heavily used paralellization and multi-threading.
Two of them where simply run directly by Suave behind an Nginx-Proxy, one used IIS.
Running under IIS did not have any measurable influence on the performance.
When I came across any performance issues, Suave was never the place too look for them.
When utilizing the awesome concurrency and parallelization features of F#, your application will benefit from vertical scaling.
For example, I built an image processing service which performed rather bad on AWS, but great on a notebook with a quad core Pentium processor.
But again, this has nothing to do with Suave.
Actually it pretty much goes out of your way.
Suave itself is a great, and solid choice. In about 2 years, I did not run into edge cases, where Suave would be the cause of trouble.
I have to mention, that my expeciences are based on simple web servers and services.
Suave was used for a fairly flat web layer to serve RPC or REST-APIs.
Other tasks, like streaming or soft-realtime applications maybe would require another approach, and might not be suited well for Suave.
I am trying to develop an iOS application that stores and loads data to and from a server. The data needs of the client can be pretty much narrowed down to REST. MY question is, is REST something widely used for data/server driven iOS applications? is there a paradigm proven better or more suitable for iOS apps?
if REST is the way to go, what server environment would you choose? what server side Technology? PHP? Java? something else? We'd set up a test/dev environment at first, but eventually we are going to deploy on services like Amazon cloud or any other hosting/cloud service.
Any insight will be most welcome.
So are you writing the backend too?
Most projects that I've worked with in the past few years use REST. It's made little difference in the implementation of the iOS app (I think...). I'm more concerned about the type of data I'm consuming, which is usually JSON - and ensuring that it is as lean as possible. People writing web services should be concerned about REST.
I've also worked with projects this year that use different technologies on the backend. Java on one, and Ruby on Rails on the other.
I know another guy who uses PHP on one project, and Ruby on another.
If I was to do a backend, I'd probably use Java - solely because I know it. Not the best excuse to pick a technology - but as a full time iOS developer, I don't have time to learn something new that I won't use very often.
If you are going to deploy on a cloud based service, see what technologies they support. Maybe picking the common denominator would be a wise choice to keep your options open. Some languages tend to have more expensive server hosting costs. Java is usually more expensive than PHP to host, I guess due to the complexities of running shared java VM's instead of PHP interpreter.
I'm currently working on a project where we migrate a web application, which uses the ZK-framework, to a eucalyptus cloud enviroment, but we wonder how we can make the framework scalable. Is it even scalable?
Thanks in advance.
Sure, ZK can be scaled well. One of ZK's clients is building an application targeting 20 millions users. The application passed the stress test a couple months ago.
Like JSF or other server-side solutions, ZK has to hold the states of UI at the servers (unless you take the pure-client approach). It means you have to make the states serializable if you'd like to support failover. You could refer to http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/Clustering for more information.
On the other hand, the access of UI states in one browser window won't block the acess of another browser window. The access is done in fully parallel. The bottleneck, from our consulting experiences, is usually from the backend services rather than UI. Anyway, depending on your targeting scale and the application's complexity, there are several architectural approaches, such as using a load-balance dispatcher in front of UI layer, running UI layer in a separated server, etc.
I am not familiar with eucalyptus, so not sure if anything worth to notice.
FastCGI is old but it still seems like it must be the right answer in some cases.
It seems like the preferred deployment of Perl/Catalyst web applications is with FastCGI.
FastCGI was popular with Rails but seems to no longer be. (Why?)
The Java world doesn't seem to have anything to do with FastCGI. Is something like Tomcat way better than Apache+FastCGI?
Is choosing FastCGI still a good idea or just a lingering technology?
Ted
Since it depends a lot on your setup and requirements, I'll let the "Is X still a right answer?" up to you. However, by looking at different architectures, you can come up with a list of questions to ask to determine if it still is a right answer given specific circumstances.
Concerns of frequent interest
The questions you'll want to ask are usually related to security and flexibility. For security, you'll want to follow the principle of least privilege. For flexibility, you'll want to know if you can run multiple frameworks, multiple versions of the framework and how easily you can delegate work to other tasks.
Other concerns
For a simple web front-end to a database-backed application, not all of these questions are important. You also need to keep in mind that some of the recommendations have nothing to do with what's outlined here. Many web frameworks will recommend whatever architecture is easiest to setup with their framework. They do this because it helps get new users trying out the framework with minimal fuss and without flooding the mailing list. Also, the Java community tends to stick to a common denominator rather than take full advantage of the platform at hand, so they'll often recommend an all-Java solution.
Popular architectures
Single process architectures
From a pure performance point of view, a single process (probably threaded) with an embedded framework probably gives most performance as it reduces most communication overhead between whatever receives the request and whatever produces a response.
Security: a single process must have all of the permissions required to perform every single task it is handed. In simple applications, this might not be a problem. However, its possible you might serve multiple services
Flexibility: probably can't run multiple version of the same framework (e.g. code for different parts of your website require different versions of Java, Rails, Python, etc.). Moreover, changing your setup to serve some work on different machines becomes painful (less difficult when split up on virtual hosts).
Sub-process based architectures
Under the CGI model, you have to pay the price of spawning a new process for each request. Even on UNIX machines where spawning a process is considered cheap, 600 requests a second will kill your server if you spawn a process for each.
Security: to spawn child processes under different user accounts, your gateway probably runs under quite high privileges.
Flexibility: additional flexibility for the multiple frameworks, multiple versions, multiple languages approach, but you're still stuck on the same machine.
Distributed architectures
The FastCGI/SCGI approach tried to solve the CGI process management problem in a clean way. Just keep the process alive. Have the gateway talk to that process to serve the request.
Security: Because the gateway doesn't spawn the processes that serve requests, the gateway can run with far less privileges enabled. Actually, if it only serves as a gateway and doesn't do any work itself, it can run with hardly any privileges at all.
Flexibility: you get even better flexibility than the CGI model because you can forward the request to any machine on the network.
Conclusion
I like FastCGI, because it gives me high flexibility at a price (i.e. request forwarded through socket) I can afford to pay. It's not my full time job to administer systems. I don't develop all the apps I hosts. This means I look for the easiest solution for hosting whatever I try to host. FastCGI popular enough to be supported by major web servers and popular web frameworks. Adding another app usually just boils down to installing and mapping the desired URL to the application over FastCGI.
How can i write a cloud-aware application? e.g. an application that takes benefit of being deployed on cloud. Is it same as an application that runs or a vps/dedicated server? if not then what are the differences? are there any design changes? What are the procedures that i need to take if i am to migrate an application to cloud-aware?
Also i am about to implement a web application idea which would need features like security, performance, caching, and more importantly free. I have been comparing some frameworks and found that django has least RAM/CPU usage and works great in prefork+threaded mode, but i have also read that django based sites stop to respond with huge load of connections. Other frameworks that i have seen/know are Zend, CakePHP, Lithium/Cake3, CodeIgnitor, Symfony, Ruby on Rails....
So i would leave this to your opinion as well, suggest me a good free framework based on my needs.
Finally thanks for reading the essay ;)
I feel a matrix moment coming on... "what is the cloud? The cloud is all around us, a prison for your program..." (what? the FAQ said bring your sense of humour...)
Ok so seriously, what is the cloud? It depends on the implementation but usual features include scalable computing resource and a charge per cpu-hour, storage area etc. So yes, it is a bit like developing on your VPS/a normal server.
As I understand it, Google App Engine allows you to consume as much as you want. The back-end resource management is done by Google and billed to you and you pay for what you use. I believe there's even a free threshold.
Amazon EC2 exposes an API that actually allows you to add virtual machine instances (someone correct me please if I'm wrong) having pre-configured them, deploy another instance of your web app, talk between private IP ranges if you wish (slicehost definitely allow this). As such, EC2 can allow you to act like a giant load balancer on the front-end passing work off to a whole number of VMs on the back end, or expose all that publicly, take your pick. I'm not sure on the exact detail because I didn't build the system but that's how I understand it.
I have a feeling (but I know least about Azure) that on Azure, resource management is done automatically, for you, by Microsoft, based on what your app uses.
So, in summary, the cloud is different things depending on which particular cloud you choose. EC2 seems to expose an API for managing resource, GAE and Azure appear to be environments which grow and shrink in the background based on your use.
Note: I am aware there are certain constraints developing in GAE, particularly with Java. In a minute, I'll edit in another thread where someone made an excellent comment on one of my posts to this effect.
Edit as promised, see this thread: Cloud Agnostic Architecture?
As for a choice of framework, it really doesn't matter as far as I'm concerned. If you are planning on deploying to one of these platforms you might want to check framework/language availability. I personally have just started Django and love it, having learnt python a while ago, so, in my totally unbiased opinion, use Django. Other developers will probably recommend other things, based on their preferences. What do you know? What are you most comfortable with? What do you like the most? I'd go with that. I chose Django purely because I'm not such a big fan of PHP, I like Python and I was comfortable with the framework when I initially played around with it.
Edit: So how do you write cloud-aware code? You design your software in such a way it fits on one of these architectures. Again, see the cloud-agnostic thread for some really good discussion on ways of doing this. For example, you might talk to some services on GAE which scale. That they are on GAE (example) doesn't really matter, you use loose coupling ideas. In essence, this is just a step up from the web service idea.
Also, another feature of the cloud I forgot to mention is the idea of CDN's being provided for you - some cloud implementations might move your data around the globe to make it more efficient to serve, or just because that's where they've got space. If that's an issue, don't use the cloud.
I cannot answer your question - I'm not experienced in such projects - but I can tell you one thing... both CakePHP and CodeIgniter are designed for PHP4 - in other words: for really old technology. And it seems nothing is going to change in their case. Symfony (especially 2.0 version which is still in heavy beta) is worth considering, but as I said on the very beginning - I can not support this with my own experience.
For designing applications for deployment for the cloud, the main thing to consider if recoverability. If your server is terminated, you may lose all of your data. If you're deploying on Amazon, I'd recommend putting all data that you need persisted onto an Elastic Block Storage (EBS) device. This would be data like user generated content/files, the database files and logs. I also use the EBS snapshot on a 5 day rotation so that's backed up itself. That said, I've had a cloud server up on AWS for over a year without any issues.
As for frameworks, I'm giving Grails a try at the minute and I'm quite enjoying it. Built to be syntactically similar to Rails but runs on the JVM. It means you can take advantage of all the Java goodness, like threading, concurrency and all the great libraries out there to build your web application.